Service-oriented architecture (SOA) is an approach to building software that supports the decoupling of core business functions from their physical implementations. In SOA, software is decomposed into a number of smaller software programs called “services.” These services are distinguished by the fact that the automation logic they encapsulate can be generic, potentially useful for many purposes, and thus reused, often with a broadened, enterprise-centric emphasis on long term governance and strategic benefit. A reusable service can be used by multiple parent software programs to automate multiple tasks.
As an organization builds more and more reusable services, it establishes a service inventory. When new programs are designed, the service inventory can be searched to identify existing services that can be utilized to automate a portion of a program. This spares program developers from having to build programming logic that already exists. Services can also be reused without disturbing the underlying implementations, thus reducing the potential for errors and greater testing when new functionality and processes are added. When multiple services are chosen to collectively automate a portion of an application or program, they are assembled into a service composition. A service composition is a set of services that are called upon to carry out a specific task or sub-task of a larger task.
SOA is different from past paradigms in that it is based on different design principles and a different underlying design philosophy with different design goals known as “service-orientation.” For example, and in contrast to SOA, the older paradigm of object-oriented analysis and design (GOAD) defines methods and attributes so as to associate behavior and data with objects. These behaviors represent functionality a class is capable of carrying out. Class properties represent a form of predefined state data associated with the class and are expressed through the definition of attributes. Attributes for an GOAD class can also be private. On the other hand, services express behaviors as capabilities in the abstract divorced from state data. Thus, SOA, while not so limited, is particularly useful for a Web services technology platform. This is because Web services rely on stateless HTTP protocol to exchange messages. Further, a Web service contract cannot define private operations. The Web services technology platform introduces unique design considerations that are readily met by SOA design principles.
Because of the increasing value of SOA, several software manufacturers have produced SOA technology platforms. However, there are a number of common problems facing development professionals interested in building SOA technology platforms, one of which is modeling. Many developers are required to use proprietary modeling technology that is tied to a particular vendor's development platform and specific technologies. However, one of the key aspects of SOA is that it allows for services to be built with different vendor platforms to work together and be assembled and reused as part of multiple compositions.
Other developers are required to work with outdated modeling tools which were built in support of older design approaches and paradigms, such as GOAD for example. Because these tools are not designed with the unique characteristics of SOA and service-orientation in mind, their usefulness is limited. Further, these tools often require programming knowledge or technical expertise on the part of the user. However, SOA is designed to support and enforce business-driven solutions. Technical architects and developers may possess programming experience, but may not possess the necessary depth of business knowledge required to model services with quality business logic representation like that possessed by business analysts. Business analysts may not have programming experience or technical expertise, but may be better suited to model services. Thus, the sole involvement of either group can have trade-offs that can negatively impact the quality of the SOA design and any resulting physical implementation.
Some developers have also chosen to work with Web service contract modeling tools. These tools are only focused on the technical interface (i.e. service contract) of the service and do not take the composition of the services into account. Or modeling tools may be focused on a single service only without the ability to provide a multitude of services or create service compositions.
Other modeling tools may force developers to immediately design the physical implementation of a service. However when building SOA platforms, it is advantageous to first allow the conceptualization of the multitude of services and compositions before committing to physical service designs and the corresponding technical interfaces.
These problems associated with modeling tools that do not fully support the design principles and paradigms of SOA can lead to significant productivity issues, and more importantly, the design of poor quality SOA implementations.